IBIS Macromodel Task Group

Meeting date: 27 January 2009

Members (asterisk for those attending):
  Ambrish Varma, Cadence Design Systems
* Anders Ekholm, Ericsson
* Arpad Muranyi, Mentor Graphics Corp.
  Barry Katz, SiSoft
  Bob Ross, Teraspeed Consulting Group
  Brad Brim, Sigrity
  Brad Griffin, Cadence Design Systems
* David Banas, Xilinx
  Donald Telian, consultant
  Doug White, Cisco Systems
  Eckhard Lenski, Nokia-Siemens Networks
  Essaid Bensoudane, ST Microelectronics
* Fangyi Rao, Agilent
  Ganesh Narayanaswamy, ST Micro
  Gang Kang, Sigrity
  Hemant Shah, Cadence Design Systems
* Ian Dodd, Agilent
  Joe Abler, IBM
* John Angulo, Mentor Graphics
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
  Kumar
  Lance Wang, Cadence Design Systems
  Luis Boluna, Cisco Systems
* Michael Mirmak, Intel Corp.
* Mike LaBonte, Cisco Systems
  Mike Steinberger, SiSoft
* Mustansir Fanaswalla, Xilinx
  Patrick O'Halloran, Tiburon Design Automation
  Paul Fernando, NCSU
  Pavani Jella, TI
* Radek Biernacki, Agilent (EESof)
* Randy Wolff, Micron Technology
  Ray Comeau, Cadence Design Systems
  Richard Mellitz, Intel
  Richard Ward, Texas Instruments
  Sam Chitwood, Sigrity
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence Design Systems
  Sid Singh, Extreme Networks
  Stephen Scearce, Cisco Systems
  Steve Pytel, Ansoft
  Syed Huq, Cisco Systems
  Syed Sadeghi, ST Micro
  Terry Jernberg, Cadence Design Systems
* Todd Westerhoff, SiSoft
  Vikas Gupta, Xilinx
  Vuk Borich, Agilent
* Walter Katz, SiSoft
  Zhen Mu, Cadence Design Systems

------------------------------------------------------------------------
Opens:

--------------------------
Call for patent disclosure:

- No one declared a patent.

-------------
Review of ARs:

- Michael M send updated IBIS Interconnect SPICE syntax document to Mike L for posting
  - Done

- Walter: Draft BIRD proposal for new keywords
  - This is cancelled

- Arpad:  Write parameter passing syntax proposal (BIRD draft)
          for *-AMS models in IBIS that is consistent with the
          parameter passing syntax of the AMI models
          - TBD

- TBD:    Propose a parameter passing syntax for the SPICE
          - [External ...] also?
          - TBD

- Arpad:  Review the documentation (annotation) in the macro libraries.
          - Deferred until a demand arises or we have nothing else to do

-------------
New Discussion:

Walter lead a discussion of the new IBIS Interconnect SPICE document:
- We started with a high level overview.
  - The Goals and Scope section lists items that it will and will not cover.
  - Syntax Rules
  - Functions and Params
  - Node Naming
  - Element, Subckt Naming conventions
  - Elements:
    - HSPICE "R=" syntax might be dropped
  - Frequency Response Table
    - Not sure who will use it, but it is left in
  - Foster Pole-Residue Form:
    - This is not well understood
  - .SUBCKT
  - S-element:
    - There are lots of options in the HSPICE manual
    - We need to find out which are important
    - SPICE tends to not be forgiving:
      - Some simulators abort, given unrecognized parameters
      - Can people add other parameters for their simulators?
  - W-element:
    - This needs work on how to point to RLGC data

Arpad: Should we combine interconnect and buffers in the same specification?
- Walter: This is a straightforward document as it stands:
  - Adding behavioral models would open up a Pandora's Box of issues
- Arpad: The new features can be incremental, based on this specification
- Michael M: Lance had asked if we will scope out a connection between
  interconnect models and buffers
  - Walter: We could have parallel efforts
  - Randy: This started with EMD, which is separate
  - Bob: Agree, IBIS Interconnect SPICE should be a separate module
    - IBIS Interconnect SPICE, EMD, and buffers should all be separate
  - Arpad: IBIS Interconnect SPICE already has voltage sources
    - We don't want to duplicate
  - Mike L: The behavioral specification could ".include" IBIS Interconnect SPICE
- Bob: We should not create new syntax where it does not exist
  - We should stick with a subset of HSPICE and live with the limitations
  - Arpad: We still need to add details
    - These documents should not require looking up in the HSPICE manual
  - Arpad: We already have pole-zero, which HSPICE does not support
    - Bob: HSPICE does support that
    - Arpad: They have controlled sources for this, but not direct support
- Michael M: We should not "bless" the Synopsys format such that others
  become imitators
  - Walter: There is nothing new here, it is all old syntax
    - We are OK as long as this is limited to interconnect
  - Randy: We would only differ if we had impulse response
    - Walter: impulse is a form of transfer function
      - S-params can be generalized to do this
      - Bob: Agree
  - Arpad: Agree with Michael M, the idea is not to promote Synopsys
    - We should not be pressured to add in everything HSPICE has
    - Radek: We do not have to follow everything in HSPICE
    - Walter: HSPICE may even take ideas from IBIS Interconnect SPICE

Walter: What we have here is a good first step
- Todd: This syntax is no more than a donated starting point
- Walter: We don't have to be concerned until we have a new proposal
- Bob: We need to be smart about this
- Todd: We have to consider what Synopsys signed onto
  - Bob: They can shut off any deviation
  - Michael M: Disagree: They have no control

Arpad: What do we do next?
- Walter: We should go through each element
  - This may take 2 or 3 weeks if we prepare
- Ian: It would be good to note vendor support for these primitives as we go
- Walter: We should resolve the resistor today

Arpad: We should plan for the next meeting
- DesignCon is next week, there will be no ibis-atm meeting
- Bob: We might have an ad-hoc meeting at DesignCon

Walter: How should we treat "R=" in resistor?
- Arpad: It should be optional
- Mike L: Having variable numbers of positional nodes and params can get tricky
  - Requiring "=" for all params solves this
  - But staying faithful to the legacy language is still best
- We agreed to make no changes to R through K 
- Walter: Should we have a special shunt element?
  - Bob: Maybe it should not have the number
    - A regular voltage source would be best

Arpad: Should we modify copy and paste into this document or reference?
- Walter: We should review what we have first

Next meeting: 10 February 2009 12:00pm PT

-----------

